In conventional resource management systems, application services typically function in connection with applications. Such application services may each manage different components of a resource. For example, two application services may manage different components of a loan approval process. Specifically, a first application service may manage a credit history component of the loan approval process, while a second application service may manage a down payment component of the loan approval process. Each of the application services may manage related service entities associated with the loan approval process. For example, the first application service may mange “applicant” service entities, while the second application service may manage related “loan” service entities.
Applications functioning in connection with the application services may be, for example, electronic mail applications, word processing applications, or spreadsheet applications that enable the production of documents. Such documents may often refer to service entities and influence the management of the service entities at the application services. For example, a document may include the text, “John Smith has missed a credit card payment.” “John Smith” may be an instance of both the applicant entity managed by the first application service and the loan entity managed by the second application service. Thus, the document may influence the management of the applicant entity “John Smith” and the loan entity “John Smith”. Specifically, the document may influence a user to change the state of the applicant entity “John Smith” at the first application service to a “deny loan” state. The document may also cause the state of the loan entity “John Smith” at the second application service to be changed to a “refund down payment” state.
Although documents may often influence the management of service entities at the application services, there is generally limited ability to access, query, and manage service entities from within an application. For example, if the document influences a user to change the state of applicant entity “John Smith” at the first application service, then, to change the state, the user must access the first application service and identify the applicant service entity at the first application service. It may often be difficult, however, to identify a service entity at a application service because a document often does not provide sufficient semantics about attributes by which the service entity is defined. For example, while the document refers to the loan applicant “John Smith” by his full name, the first application service may define the applicant service entity by separate “first name” and “last name” attributes.
The limited ability to access, query, and manage service entities from within an application is particularly cumbersome when a document influences the management of related entities from different application services. For example, if the document causes a user to change the state of applicant entity “John Smith” at the first application service and to change the state of loan entity “John Smith” at the second application service, then the user must separately access each application service and separately identify each service entity at each application service. Separately identifying of service entities at different application services is cumbersome because, even if the different service entities are related, the service entities may be defined at each application service by different sets of attributes. For example, while the first application service may define the applicant service entity by separate “first name” and “last name” attributes, the second application service may define the loan entity by an “applicant” attribute rather than by a name attribute.
Another difficulty relating to the management of service entities in conventional resource management systems is that an application typically provides limited information about the availability of actions which can be performed on service entities at the application services. Specifically, each application service may have specific rules and conditions related to the performance of actions on service entities. For example, such rules and conditions may include a maximum number of times which an action may be performed, a period in which an action must be performed, a limited user or class of users which may perform an action, or a condition which must occur before or after the performance of an action. An application generally cannot determine what such rules and conditions are and whether they are satisfied. Thus, a user must access each component process to determine if an action is available within the process.
Additionally, an application typically has limited abilities to coordinate the management of resources among multiple users according to such rules and conditions. Specifically, an application has limited ability to track the performance of actions and to prevent or advise against the performance of actions that are invalid or likely to generate conflicts. Furthermore, applications typically have limited ability to provide users with information about relationships between entities and processes managed by different application services and the performance of actions on such related entities by other users. Such information may be used to determine the availability of an action and to protect against conflicts related to the performance of the action.
Thus, there is a need in the art for systems and methods for integrating resource management between application services and applications. It is desired that such systems and methods enable, for example, matching of related service entities from different application services, association of service entities with documents, and management of service entities from within an application.